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(g) Computer conferencing method. 

(g) In an anrangement wherein a pluratity of oonrv 
puters are \\nke6 together, one computer njns 
an application program. Each computer can be 
in an application mode wherein the application 
program may be controlled, an annotation 
nrKKje wherein annotations made at one of the 
computers can be viewed at any of the compu- 
ters, or a view nK>de wherein neither application 
control nor annotations are pemnitted, but a 
common display nrtay be viewed. 
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This invention relates to operating a plurality of 
Interlinked computers. 

Modern telephone systems allow multiple parties 
at different locations to hold a conference. However, 
telephone conferences do not provide all of the con- 
veniences of a face-to-face conference, where par- 
ticipants all meet at a common table in a meeting 
room. For example, In a meeting rt>om, participants 
can view an object of Interest, such as a drawing or a 
product Such viewing is not possible in a telephone 
conference. 

It is an object of the invention to provide an im- 
proved electronic conferencing system. 

Therefore, according to the present invention, 
there is provided a method of operating a plurality of 
Interlinked computera. characterized by the steps of: 
running an application program on one of said com- 
putera and operating each computer selectively in an 
application nrnxie, or an annotation nfK>de, wherein a 
computer in application mode can operate on said ap- 
plicatnn program, and a computer In annotation 
mode can annotate its own display and cause the an- 
notattons to be displayed by the other computers as 
a common display, but cannot operate said applica- 
tion program. 

One emfc>odlment of the present inventton will 
now be described by way of example, with reference 
to the accompanying drawings, in which:- 

Figure 1 illustrates three computere, connected 
by telephone lines. 

Figure 2 initiates an example, which will be elabo- 
rated in Figures 3-14. In the example, a calculator pro- 
gram is operated, and annotated, by various parties. 

Figure 3 illustrates how the system responds 
when a host user attempts to operate the calculator, 
in Annotation mode. 

Figure 4 illustrates how the system responds 
when a host user attempts to annotate the calculator, 
In Annotation mode. 

Figure 5 Illustrates how the system responds 
when a host user attempts to operate the calculator, 
in Application mode. 

Figure 6 illustrates how the system responds 
when a host user attempts to operate the calculator. 
In Local Annotation nrK>de. 

Figure 7 illustrates how the system responds 
when a host user attempts to annotate the calculator, 
in Local Annotatton nfK>de. 

Figure 8 illustrates how the system responds to 
a host user when in View mode. 

Figure 9 illustrates how the system responds 
when a remote user attempts to operate the calcula- 
tor, in Annotation mode. 

Figure 10 Illustrates how the system responds 
when a renrwta user attempts to annotate the calcu- 
lator, In Annotation mode. 

Figure 11 illustrates how the system responds 
when a remote user attempts to operate the calcula- 



tor. In Application mode. 

Figure 12 illustrates how the system responds 
when a remote user attempts to operate the calcula- 
tor, in Local Annotation nKXIe. 
5 Figure 13 illustrates how the system responds 
when a renrrate user attempts to annotate the calcu- 
lator. In Local Annotatton ntode. 

Figure 14 illustrates how the system responds to 
a renfKtte user when in View mode. 
10 Figure 15and ISAIIIustratetoglcflowusedbythe 
system. 

Figure 1 shows three computere connected by 
telephone links. Each computer runs a message-driv- 
en, multi-tasking. Graphical User Interface (GUI), 
15 such as that sold under the name Windows, available 
from Microsoft Corporation, located in RednK>nd, 
Washington. Such GUIs are also called operating en- 
vironments. 

The user of a GUI interacts with a program by way 
20 of windows. Selected windows, rather than the entire 
display, are replicated at the remote computere. This 
selective replication allows usera to maintain private 
areas on their displays, which are not shared. Each 
computer also runs software which effects the oper- 
25 ations described herein. In additton, one computer 
(the IHost) runs an ApplicatkHi program. (It Is possible 
for the Host to run both progran^s because of the mul- 
ti-tasking capabilities of the GUI.) 

There are four basic modes of operation: 

30 

1. Application Mode 

Any user of any of the three computere in Figure 
1 can issue commands to the Applk^tion program. 
35 For example, assume the Application program is one 
which simulates a hand-held calculator. The initial sit- 
uation is shown In Figure 2, where each computer dis- 
play shows the calculator. Assume that the following 
events occur 

40 The user of the Host presses the "3" button on the 
calculator (either by keyboard input, or mouse input, 
depending upon the design of the calculator pro- 
gram). 

In response, each calculator, in its display area, 
45 shows a '3'. 

The user of one Remote presses 
The user of the other Remote presses "6". 
The user of the Host presses "=". 
At this point, all calculatore will display "9", which 
so is the sum of 3 and 6. The usera collectively operated 
the calculator program, and the display of each shows 
the result 

The calculator program does not care which 
usera pressed the txjttons, nor whether some usere 
55 pressed no buttons, provkted a legal sequence 6f but- 
tons was received. (It is assumed that the usera are 
cooperative, and that no usera try to sabotage oper- 
ation of the calculator.) 
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2. Annotation Mod« 

Any user can draw on the user's own, local, dis- 
play, using drawing tools similar to those found in a 
"painr program. The user can draw boxes, circles, s 
arcs, text, ellipses, and so on. The user can also erase 
Items on the display. 

The user's annotations are replicated on all other 
displays, so that all users view similar displays. How- 
ever, the displays could be different, t)ecause of the io 
following factors: 

(A) Different display monitors have different 
properties, such as resolution and color capabil- 
ity. 

(B) Different display protocols (EGA, VGA, etc.) is 
represent graphics images differently, and have 
different color capabilities. 

(C) Different GUIs, or different veraions of the 
same GUI, may have different display conven- 
tions. Different computere in Figure 1 could run 20 
the different GUIs. 

(D) Some users have changed the size of the win- 
dow in which their calculator is displayed, causing 
a deviation in scaling. 

These differences can cause differences in the 2S 
appearance of the displayed images, relative to each 
other, but the basic content of all displays should be 
the same. To accommodate size differences, the dis- 
plays may be drawn to different scales as appropriat- 
ed. 30 

3. Local Annotation Mode 

A user can annotate the local display, but the an- 
notations are kept private, and no other user can see 35 
the annotations. 

4. View Mode 

No usere can annotate, nor can they issue conv 40 
mands. However, an action resembling annotation 
can be taken. Users can mowe their cursors, and oth- 
ere will see the movement, allowing remote pointing. 
View Mode is useful in one embodiment, wherein, for 
example, Annotate Mode Is in force, but a specific 45 
user's nrK)de is designated as View. In this embodi- 
ment, all users can annotate, but the View" user can 
only watch, and cannot annotate. 

Figures 3.14will illustrate the different modes, by 
way of example, using the calculator program. so 

Referring to Figure 3, there is shown the situation 
where the host runs on applicatton program; the mode 
is "Annotation", the user input is at the host computer; 
and the user attempts to operate the calculator. 

Assume that the user of the host computer at- ss 
tempts to add two numbere, using the calculator. At- 
tempted entry of the first number will be considered. 

The user, located at the Host, moves the Hosfs 
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cureor over a key of the calculator, as shown In Figure 
3, and tries to depress the key. by clicking the mouse. 
However, the mouse click is blocked and does not 
reach the Application program. The Appiicatton pro- 
gram does not respond, because it receives no 
mouse dtok. 

That is. In more detail, the GUI detects the mouse 
movement, and causes 'nxxjse messages" to be gen- 
erated. The GUI places the mouse messages into a 
queue, where they await processing. INPUT ROUT- 
ER in Figure 1 5 reads these messages. Because "An- 
notation Mode" Is currently In force. INPUT ROUTER 
directs the messages to ANNOTATION block. APPLI- 
CATION does not receive the messages and thus 
does not respond. The mouse dick is ignored. 

ANNOTATION can be configured to respond to 
two (or more) ways to the mouse messages. In one 
configuration, annotation requires the nuMise to Ini- 
tially select an ANNOTATION TOOL If no selection is 
done, ANNOTATION ignores nrK>use messages. 

Selection is done by dicking the nKHJse over an 
image of the tool, as is commonly done in "painr pro- 
grams. ANNOTATION recognizes this tool selectton, 
and then treats subsequent mouse dteks as data for 
drawing with the selected tod. For example, if a rec- 
tangle tool were selected, the next two mouse dicks 
would define the diagonal cornere of the rectangle. 
(Figure 4, later discussed, illustrates drawing a rec- 
tangle.) 

Under the second configuration, a defeult tod, 
such as a pen, is autonr^tk:ally selected when in An- 
notation Mode. In this configuration, when the user 
tries to depress a calculator button (by dk:king on it), 
the user (unintentionally) initiates drawing of a line, 
using the pen. When the user recognizes this, the 
user can terminate drawing of the line, in any of sev- 
eral known ways. 

Therefore, in Annotation Mode, the system either 
(a) responds to nnouse input by initiating a draft an- 
notation, or (b) ignores the mouse input, because an 
annotation tool was not selected. Keyboard input 
from the user is treated the same way. Of couree, 
other responses by ANNOTATION can be designed. 

Each display Shows a cursor whose positton Is 
controlled by the associated mouse. Each cursor is 
replicated on all displays. Thus, in Figure 3, with three 
mice, there are three cursors on each display (only 
one is shown for simplicity). Consequently, when one 
user moves a nrKMise, the corresponding cureor 
moves on all displays. In general, the three cureore 
are distinguishable: each cursor Mentif les its owner, 
as by color, shape, indusion of a label, or the like. 

Refening to Figure 4, there Is shown the situation 
where the host runs an applk:ation program; the 
mode is "Annotation"; the user input is at the host 
computer; and the user attempts to draw a box over 
the calculator. 

This situation is quite similar to that of Figure 3, 
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except that, now, the user intends to draw an annota- 
tion, instead of intending to press a tHJtton, as in Fig- 
ure 3. 

Assume that the user of the host computer draws 
a box over the caiculator. (The t>ox is shown overiy 5 
iarge. for emphasis. It Is preferred that the box not ex- 
tend beyond the calculator itself.) The box Is replicat- 
ed on the remote computers. (The box Is drawn using 
annotation tods, which are not shown.) 

In terms of Figure 15. INPUT ROUTER directs io 
the logic flow to ANNOTATION. ANNOTATION call 
the proper GDI functions to draw the box. Also. AN- 
NOTATION sends "annotation messages" to CON- 
NECTION API, which delivers the annotation mes- 
sages to the RenK)tes. is 

ANNOTATION In Figure 1SA receives the anno- 
tation messages. This ANNOTATION block repre- 
sents the logic executed at each fstnote computer. 
This ANNOTATION calls the proper GDI functions, via 
the block GDI. 20 

"GDI" Is an acronym for Graphical Device Inter- 
face. "GDI functions" are small programs, contained 
in a larger program of the GUI called GDI.EXE. A GDI 
function, when called, draws a specific graphic im- 
age, such as a circle, box. or text, based on subse- 25 
quent Input from the user. Other GDI functions per- 
fcmn other tasks, such as selecting pen widths. 

GDI.EXE is a commercially available product. 
Technical details concerning GDI.EXE are contained 
in "Windows Software Development Kit," available 30 
from Microsoft Corporation, and in Programming 
Windows 3.1 by Charles Petzotd (Microsoft Press, 
Redmond, Washington, 1992. ISBN 1-55615-395-3). 

Referring to Figure 5, there is shown the situation 
where the host runs an application program; the mode 35 
is "Application"; the user input is at the host computer, 
and the user attempts to use the calculator. 

The user of the Host mowes the cursor over the 
calculator key "3" and dicks the mouse. The GUI gen- 
erates a mouse message and places it into the queue. 40 
The mouse message is read, and passed to the Ap- 
plication program (ie. the calculator program), which 
responds by (1) showing that the key "3" is depressed 
and (2) drawing the numeral "3" in the calculator's dis- 
play, using GDI calls. The Apptlcatk>n program also 45 
records the fact that the user enters a "3", for its own 
internal operations. 

The GDI calls made by the Applicatk)n program 
in drawing the "3" In the calculator, and in drawing the 
depressed "3" button are Intercepted, and notified to so 
the other computera. The other computere replicate 
the Host display, by executing the same GDI func- - 
tions. Greater detail concerning this GDI Interceptton 
is given later. 

Thus, all usere simuttaneou^y see the user of the 55 
Host operate the calculator. (The action is not exactly 
simultaneous, because extremely short delays are in- 
volved. However, a hunran probably could not detect 



the delays if the Host and the Remote were operating 
skle-by-side.) 

In terms of Figure 15. the INPUT ROUTER rec- 
ognizes that the mouse messages should be directed 
to the Application program, and directs the logk: flow 
to APPLICATION (ie. the calculator program). APPLI- 
CATION (1 ) draws a depressed "3" key and (2) writes 
the numeral "3" on the calculator's display, by calling 
appropriate GDI functtons. 

However, the system, via GDI CAPTURE In Fig- 
ure 15, captures the Application program's GDI calls, 
before they are executed. Two things are done with 
the captured calls. One, the other computere are no- 
tified of these calls, via the block CONNECTION API. 
This action leads to block CAPTURED GDI DISPLAY 
in Figure 1 5A. which causes each Remote to execute 
the same GDI functions, as indicated by block GDI. 
Two, the system allows the GDI functions, called by 
the Application program, to be executed at the host, 
via the block GDI in Figure 15. Therefore, GDI func- 
tion calls nDade by the Appllcatton Program are cap- 
tured and notified to the Remote computere. so that 
the Remotes can duplk^te them. The captured calls 
are then executed as intended on the Host 

Referring to Figure 6, there is known the situation 
where the host runs an application program; the 
mode Is "Local Annotatk)n"; the user input is at the 
host computer; and the user attempts to operate the 
calculator. 

Assume that In Annotatton Mode, there is no de- 
fault annotation tod given to the user. Under this as- 
sumption, if the user nr>oves the curaor to a calculator 
button, and tries to "press" the button, the INPUT 
ROUTER in Figure 15 passes the mouse message to 
the annotation block. Since the mouse dick is not part 
of a valid annotation input sequence (no tool was se- 
lected), ANNOTATION draws nothing. Further, the 
Remote computere do not show the nravement of the 
cursor corresponding to the Host computer's mouse, 
as Indicated, because line 5 in Figure 15 does not 
send Annotation Messages to the other computere 
when Local Annotation Is in force. Further still, the 
calculator button is not re-drawn as a depressed but- 
ton on the Host display, in response to the attempt to 
press it, because APPLICATION did not receh^e the 
mouse message. APPLICATION is responsible for 
drawing depressed calculator buttons. 

if a default annotation is assigned to the user In 
Local Annotation Mode, the user's nrwuse dick would 
initiate drawing by that tool. When the user realized 
the mistake, the user would terminate the drawing, In 
a known manner. 

Referring to Figure 7, there is shown the situatton 
where the host runs an appik:ation program; the 
mode is "Local Annotatton"; the user Input Is at the 
host computer; and the user attempts to annotate the 
calculator. Under these conditk>ns, the INPUT ROUT- 
ER in Figure 1 5 recognizes a vaikJ attempt to perform 
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annotation, as by drawing a box. The INPUT ROUT- 
ER directs the logic flow to the ANNOTATION block, 
which calls the proper GDI functions for drawing the 
annotation, namely, a box. as shown In Figure 7. How- 
ever, because the annotation is local, no boxes are s 
drawn on remote computers, as Indicated in Figure 7. 
No data is sent along data path 5 in Figure 15. 

Referring to Figure 8, there is shown the situation 
where the host runs an application piogram; the tnode 
is "View"; the user input Is at the host computer; and io 
the user attempts to operate the calculator. As Figure 
8 indicates, the mouse dick to ignored, and nothing 
happens at the Renrrates. In Figure 15, the INPUT 
ROUTER reads the mouse nnessage, but blocks it 
from APPUCATION, because the current mode is 15 
"view." 

Referring to Figure 9, there is shown the situation 
where the host runs an application program; the mode 
is "ANNOTATION"; the user input is at a remote conrv 
puten and the user attempts to operate the calculator. 20 

Assume that the user moves the mouse cursor 
over a calculator button and clicks the nrKMJse. The 
mouse Glk:k is ignored. The other computers (Host 
and the other Remote) show the tmiion of the user's 
cursor, but nothing else, because no tool has been se- 2S 
lected. In Figure ISA, the INPUT ROUTER blocks the 
mouse message from reaching APPUCATION. The 
logic is directed to ANNOTATION, which draws a cur- 
sor on the user's Remote display, via block GDI. AN- 
NOTATION also sends data to CONNECTION API, 30 
which directs the logic to ANNOTATION in Figure 15. 
This ANNOTATION represents the annotation logic 
present on the two other computers: the Host and the 
other Remote. These ANNOTATION blocks draw cur- 
sors corresponding to the users cursor, at corre- 35 
spending positions, via the GDI block in Figure 15, 
which represents GDI function calls. The Host can 
use one tool, such as a box-drawing tod. while a Re- 
mote can use a different tod, such as a circle-drawing 
tool. 40 

Referring to Figure 10, there is shown the situa- 
tion where the host run an application program; the 
mode is "ANNOTATION"; the user input is at a remote 
computer; and the user attempts to annotate the cal- 
culator. Assume that the annotation is a box. A box is 45 
drawn on ail displays. In Figure 15A, the INPUT 
ROUTER at the user's Remote directs the mouse 
messages to the block ANNOTATION. ANNOTATION 
does two things. One. it calls the proper GDI functions 
to perform the annotation, nannely. drawing the box. so 
Two, ANNOTATION sends annotatk>n messages to 
CONNECTION API, which delivers the annotatton 
messages to the other computers. However, one of 
these is the Host, and the other is a Remote. The logic 
at the Host reaches ANNOTATION in Figure 15, and 55 
the logic at the other RenrK>te reaches ANNOTATION 
in Figure 15A. 

Both of these ANNOTATION blocks cause the 



proper GDI functions to be called, to draw an annota- 
tion corresponding to the user's annotatk>n. However, 
in the Host, logic path 5 is not taken at this time, be- 
cause it is not necessary to replicate the Hosf s an- 
notations at other computer. 

Referring to Figure 11, there is shown the situa- 
tion where the host runs an applicatkHi program; the 
user input is at a remote computer and the user at- 
tempts to operate the calculator. It will be recalled that 
the calculator program is loaded only on the host, 
while a Remote user wishes to operate It 

The Remote user's INPUT ROUTER in Figure 
15A routes the nrNMJse messages to CONNECTION 
API. The Host receives these messages, which are 
delivered to the Hosfs INPUT ROUTER in Figure 15. 
The Hosfs INPUT ROUTER directs the noessages to 
the block APPLICATION (ie. to the Application pro- 
gram, namdy, the calculator program), which does 
two important things. 

The calculator program treats the messages as 
though they were issued by the Hosfs mouse, even 
though a Reniote mouse caused them. The calculator 
program responds in its usual way, which indudes (1 ) 
showing a depressed calculator button "3", (2) writing 
the numeral "3" in the calculator's display, and (3) 
performing its own internal computations when tt 
learns that the user entered data (nannety, the '3*). 

However, before the calculator program can exe- 
cute (1) and (2) in the previous paragraph, the system 
first captures the GDI functions whteh the calculator 
program calls. This capture is illustrated in btock GDI 
CAPTURE in Figure 15. During this capture, the sys- 
tem, in effect, does two things. One, it sends these 
GDI functions to CONNECTION API (for the other 
computers to use). At the user's Remote, CONNEC- 
TION API in Figure 15A directs the GDI functtons to 
CAPTURED GDI DISPLAY, which replicates the 
Hosfs display. Two, it causes the GDI f uncttons to be 
executed at the Host (via block GDI in Figure 15). 
Therefore, the general sequence of events is the fd- 
towing: 

The Remote user attempts to press a calculator 
button. 

The software running on the Remote detects this 
attempt, and sends data to the calculator program 
running on the host The data takes the form of mes- 
sages which the calculator program "thinks" come 
from the Hosfs nrxMJse. 

The calculator program performs as usual, and 
draws images on the Host display, via GDI calls. 

The system captures the GDI calls, and informs 
the Remotes of them. 

The Renwtes replicate the Hosfs window. The 
Remote user thus can remotdy operate the calculator 
program running on the Host 

Summarizing in a different way: n>ouse messag- 
es are generated at the Host based on nvouse mes- 
sages at the Remote. The calculator program (run- 
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ning on the Host) responds to the mouse messages 
as though they were generated at the Host The GDI 
calls made by the calculator program are Intercepted, 
and executed at the Remote, thereby replicating the 
Hosfs display at the Remote. 

Refeiring to Figure 12, there is shown the situa- 
tion where the host runs an application; the mode is 
"Local Annotation', the user input is at a tewtito conv 
puter, and the user attempts to operate the caiculator. 
The user's mouse click is ignored. Nothing appears 
on the other displays in response to the mouse move- 
ment, because of failure to select a tod. 

Referring to Figure 13, there is shown the situa- 
tion where the host runs an application program; the 
mode is "Local Annotation"; the user input is at a re- 
mote computer; and the user attempts to annotate the 
calculator. The annotation is drawn on the user's dis- 
play, as indicated. No annotation occurs on the other 
displays. 

RefOTfng to Figure 14, there is shown the situa- 
tion where the host runs an application program; the 
mode is "View"; the user input is at a remote comput- 
er; and the user attempts to operate the calculator. As 
indicated, the mouse cursor moves at the user's dis- 
play, but the nrKMise dick is ignored. Further, the other 
two displays show the nuivenient of the user's nriouse 
cursor. 

With regard to the above situation descriptions, 
the following points should be noted. The displays are 
drawn using GDI functions. However, diffmnt parts 
of a display are drawn by different programs. 

Despite the feet that all these drawing operations 
are undertaken using GDI functions GDI functions 
are not the exclusive medium of communicatton be- 
tween computers for replicating the displays. For ex- 
ample, when a user performs annotation, the user's 
mouse messages are replicated, as messages, at the 
other computers, via path 5 in Figure 1 5. These repli- 
cated messages then cause the respective ANNOTA- 
TION blocks (at the other computers) to issue the 
proper GDI calls for drawing the annotation. That is. 
GDI calls are not send directly from the user perform- 
ing the annotatkm to the other computers. 

In contrast, when an application program causes 
a graphic image to be drawn on a display. GDI calls 
are intercepted via GDI CAPTUF^ in Figure 15) and 
caused to be replicated on the other computers. 

A major reason for the two different procedures 
(replicating nrxHise messages and replicating GDI 
calls) is that annotations are stored in memory at dif- 
ferent locations than the display infbrmatton. That is. 
returning to the calculator of Figure 2, the Application 
program stores the image of the calculator in the fol- 
lowing general way. Annotatk)n data is stored. Appli- 
cation program data is stored by the Applicatton pro- 
gram (at the host). Each image of a key is stored as 
data from whk:h a GDI function can draw the key. The 
data includes information such as position, size, col- 



or, and so on. Each key includes an associated nunv 
ber. The number can be stored as a text character, 
with information as to position, size, font type, and so 
on. Annotatbn data is stored at a different location, 
5 but In the same general way. If either the annotatton 
or the Application program needs bitmaps, the bit- 
maps are stored in a conventtonal, known manner, by 
the GUI. 

The annotatk>n images are combined with the 
10 Application's images by the known technique of 
masking. That is, at a RenDote, the receh^ed GDI func- 
tions are executed into a bitmap. The received anno- 
tation Information is executed into a different bitmap. 
The two bitmaps ara ntasked together. The annota- 
15 tion data is kept separate from the application data so 
that, for example, a user can save an Applicatton inrv 
age, but without annotations. Alternatively, a user can 
save annotation data alone, or save an annotated dis- 
play. 

20 As another example, keeping the annotation data 
separate facilitates drawing a display having no anno- 
tation data. If the annotation data were intermingled 
with the calculator image data, elimination of the an- 
notation data would be difficult, if not impossible. If 
25 GDI calls were transmitted exclusively (ie. no mes- 
sage replication were undertaken), then extra effort 
would be required to construct annotation data for 
separate storage. 

GDI interception can be understood as follows. 
30 A. On start-up, the first five bytes of each GDI 
function are replaced with a JUMP instructk)n to 
a particular program, namely, Trap.GDI. 

B. Trap.GDI gets the parameters for the desired 
graphics image (eg. in the case of a t>ox, the lo- 
ss cations of the two diagonal corners) and calls the 

sub-program PkgDispCall. Trap.GDI also replac- 
es the first five bytes. 

C. PkgDIspCalt accepts the paranwters from 
Trap.GDI and generates an object structure. This 

40 object structure is a block of data containing ev- 
erything necessary for the other computers to 
draw the box. 

For example, the object structure contains 
information as to size and position of the tx>x. 

45 Further, the GUI draws images within a "context". 
The context includes things such as pen wklth, 
color, and other features. The contexts of the in- 
dividual computers are tracked. If the context of 
the box drawn is different from the contexts of the 

50 remote computers, PkgDispCall includes data 
necessary for the other computers to create the 
correct contexts. 

D. The object structure is shipped to the other 
computers, which then execute the same GDI 

55 functions. 

E. The invention executed the original GDI func- 
tions. 

The displays are not replicated bit-by-bit For ex- 
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ample, the image of the calculator In Figure 2 could 
be transferred tMtween computers in bitwise fashion. 
If the calculator occupied a space of 200 x 300 pbcels, 
then information regarding 60.000 (ie. 200 x 300) pbc- 
els murt be sent s 

Instead, the particular calculator image shown In 
Figure 2 is treated as eighteen rectangles, plus a text 
character for each of sbdeen of the rectangles, giving 
a total of 34 objects. Each object requires parametere, 
such as size and position. The number of parameters io 
is small, in the range of three to ten. Assuming ten 
parametere, then 340 pieces of data must be sent Of 
course, the size of each piece depends on many fac- 
tore, but a smafl number of bytes for each piece may 
be assumed. is 

Therefore, the 60,000 pieces of data needed for 
bitwise replication once reduced to 340 pieces maxi- 
mum for object replication. Of course, some objects 
may take the form of bitmaps, and must be sent bit- 
by-bit However, In general, bitmaps are expected to 20 
be rare. Further, it is expected that, in general, bit- 
maps, when sent, need be sent only once. Also, the 
object data is compressed when possible. That is. ev- 
ery transmission between oomputere is of com- 
pressed data, when possible. Compression is known 25 
in the art 

Communicatton anmng oomputere can take sev- 
eral fonms. Commercially available networks, local 
and wkle area, can be used. Commercially available 
ISDN telephone service, provided by local telephone 30 
companies, can be used. Modem communication can 
be used. There are commercially available packages 
which detect nrwssages generated by the GUI in re- 
sponse to an input device. One such package is WIN- 
SIGHT, available from Borland International. 35 

An alternative approach to the graphics capture 
described above is the following. The system-provid- 
ed GDI is replaced by a separate procedure which 
processes GDI calls before calling the actual system 
GDI. The system GDI name is changed to prevent 40 
confusion between the two modules. The same tech- 
nique is also used on USR.EXE to also capture GDI 
calls made through systenD-provided modules. 

A given computer can act as a Host for one pro- 
gram and a Remote for another. For example, one 45 
computer can run a word processing program. An- 
other computer can run a CAD drawing program. 
Each is Host for its respective program. 

Since the software on each computer is identical, 
or substantially identical, all usere can run either the so 
word processing program or the CAD program, in the 
manner described above. 

There are two types of •cureor*. Each GUI gen- 
erates its own "real" cursor. The real cursor is not gen- 
erated tyy GDI functions, but by an independent f unc- 55 
tion in the GUI. The reader can view the cureor as a 
bitmap which the GUI moves in response to mouse 
motion. 



In addition to the real cursor, whteh Is controlled 
by the local mouse, the system generates a "pseudo" 
cureor for each renx)te participant The pseudo cur- 
sore are generated using GDI functions. 

Sometimes a real cursor changes shape as the 
cureor moves. For example. It can take the form of an 
arrow when tying on a tool bar, and then change to a 
hand when lying on a client area. Sometimes this 
change is under the control of the Appltoatbn pro- 
gram. Therefore, If Remote user Is controlling an Ap- 
plicatton program running on a Host machine (as In 
Figure 11), the Appllcatbn program may change the 
cureor on the Host machine, but without using GDI 
calls. Consequently, the GDI capture of Figures 15 
and 1 5A wi II be ineffective to replicate the changes on 
the Remote display. 

To confront this problem, the system watches for 
the functions which change the real cursor (eg. the 
SetCursor command). The cursor change Is replicat- 
ed on the Remote computer. One way Is to execute 
the same SetCursor command. An alternative ap- 
proach would t>e to change the Remote cursor by exe- 
cuting a proper sequence of GDI calls, or to draw a bit- 
map, when the Host cureor changes. 

It should be underetood that the system only rep- 
licates windows which the user of a display kJentlfies. 
That is, the user can keep a workspace, such as a 
notepad, private during a conference. GDI calls use a 
task handle. If the task handle does not refor to a 
shared item, the GDI calls are not shared. 



Claims 

1. A method of operating a plurality of Interlinked 
computere, characterized by the steps of: running 
an application program on one of sakJ computere 
and operating each computer selectively In an 
application mode, or an annotatton nruxie, where- 
in a computer in application mode can operate on 
said application program, and a computer in an- 
notation mode can annotate its own display and 
cause the annotations to be displayed by the 
other computere as a common display, but can- 
not operate said applk:ation program. 

2. A method according to claim 1, characterized In 
that each computer can operate In a viewing 
mode wherein said common display may be 
viewed but applicatfon program operations and 
annotations are inhibited. 

3. A method according to daim 1 or daim 2. char- 
acterized by the step of running a message-driv- 
en operating system on each computer, intercept- 
ing n^sages provided by the operating system 
of a computer operating in application nfK>de, and, 
if the messages are directed to the application 
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program, causing all computers to receive the 
messages. 

4. A computer system for carrying out a method ac- 
cording to any one of the preceding claims, In- 6 
duding a plurality of Interlinked computers each 
operable selectively In an application or an anno- 
tation mode. 
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